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Arriere plan de rinvention 
5 La pr6sente invention concerne la gestion des 6venements 

dans un syst^me informatique standard comportant une unite centrale 
connectee a des unites m^moires et des periph^riques par un bus 
d' informations permettant un montage multi-mattre. 

La gestion de certains processus necessite de prendre en 
.10 compte la detection de parametres et I'envoi des instructions de 
commande appropriees en temps r^el ou dans un temps extremement 
court de I'ordre de la microseconde (|Js). Ce type d'application se 
rencontre dans le domaine a^ronautique ou spatial ou dans la gestion 
de certains processus industriels. 
15 li existe des systemes de gestion en temps reel bas6s sur des 

controleurs logiques programmables. L'inconv6nient de ces 
controleurs logiques est leurs faibles puissances de traitement et 
surtout leurs incompatibHit§s avec les reseaux informatiques 
classiques. En effet, la nature specifique des systfemes bas6s sur les 
20 controleurs logiques ne permet pas de connecter ces systemes h un 
r6seau informatique d'architecture standard. 

Par ailleurs, dans un systeme informatique standard par 
exemple a base d'un micro-ordinateur, equip6 de canaux de 
communication ou bus d'informations rapides (par exemple le bus PCI) 
25 et pilote par un systeme d'exploitation multitache (par exemple 
Windows NT), la gestion en temps reel n'est pas possible entre 
diff^rentes unites du systeme informatique. 

La figure 13 montre de fagon tres schematique, un systeme 
informatique standard comportant une unite centrale 10 pilot^e par 
30 une horloge par exemple a lOMHz (non representee), une unit§ 
memoire 20 et des peripheriques 30, 40 auxquels est ajoute un 
environnement logiciel ou systeme d'exploitation necessaire au 
traitement de I'information. L'unite centrale 10 assure la commande et 
les operations arithm§tiques et logiques. L'unite memoire 20 
35 comprend aussi bien de la memoire vive 21 que de la memoire morte 
23, tandis que les peripheriques comprennent des interfaces d'entr^e 
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et de sortie. Les echanges de donnees, d'adresses, de signaux de 
commande et de synchronisation entre les differentes unites du 
systeme informatique s'operent grace a un bus d'informations 50. 

Dans un tel systeme informatique standard, equipe d'un 
5 systeme d'exploitation dit « temps reel », rien n'est prevu pour traiter 
precis6ment et rapidement Tarrivee de signaux discrets ou de donnees 
sur le bus d'informatlons 50. Ce genre de systeme d'exploitation ne 
permet qu'un dialogue entre I'unite centrale et une autre unite et 
avec des temps de reponses de I'ordre de la milliseconde (ms) qui sont 
10 inadaptes pour des processus comportant des parametres importants 
et tr^s sensibles comme dans les domaines a§ronautique et spatial. 

Objet et resume de rinvention 

L'invention a pour but de remedier a ces inconvenients et 
15 propose a cet effet un procede de gestion des evenements, dans un 
systeme informatique standard comportant une unite centrale 
connectee a des unites memoires et des peripheriques par un bus 
d'informations permettant un montage muIti-maTtre. 

Le procede comprend les etapes suivantes : 
20 - recevoir les evenements, 

- dater et stocker ces evenements, 

- attribuer au molns une action appropri^e ^ chaque §venement regu, 

- executer cette action en reponse a r6v6nement regu, 

de sorte que les etapes de gestion precitees sont realisees en temps 
25 reel sans acc§der a I'unite centrale, par une unit§ de gestion compris 
dans un module de gestion independant relie au bus d'information et 
implante dans le systeme informatique standard. 

Ainsi, un systeme Informatique standard est transforme en 
un systeme temps reel par I'implantation d'un unique module de 
30 gestion additionnelle. 

Chaque evenement regu est stocke dans une premiere 
memoire associee a I'unite de gestion et la gestion en temps reel est 
de I'ordre d'une microseconde. 

De preference, ie module de gestion independant est isole 
35 de I'unite centrale par un pont. 




faction a ex6cuter est lue dans une table des actions 
associee a I'unlt^ de gestion et est preprogrammee au travers du bus 
d'informations. 

Avantageusement, les §venements regus par I'unite de 
5 gestion sont dates avec une precision de I'ordre de 100 nanosecondes 
et stockes en outre dans une seconde memoire associSe a T unite de 
gestion permettant ainsi de lire ces evenements aux travers du bus 
d'informations af in d'enregistrer et de controler ces evenements, 

Les evenements regus par Tunite de gestion peuvent etre 
10 generes par un registre d'horloge interne au module de gestion, par 
une unite adjacente au module de gestion ou par un equipement 
exterieur au systeme informatique. 

Les evenements requs par I'unite de gestion sont 
synchronises a une frequence correspondante a celle d'une horloge 
15 interne au systeme informatique. 

Selon un mode particulier de {'invention, les evenements 
regus de I'equipement exterieur sont filtres afin d'eliminer d'6ventuels 
parasites. 

Avantageusement, une interruption est generee par I'unite 

20 de gestion lorsqu'un ev6nement ne peut pas etre associe a une action. 

L'invention a aussi pour but de fournir un module de 
gestion des evenements implante dans un systeme informatique 
standard comportant une unit6 centrale connectee S des unites 
memoires et des peripheriques par un bus d'informations permettant 

25 un montage multi-maTtre, ledit module de gestion comprend : 

- une unite de gestion independante, reliee au travers une interface a 
I'unite centrale via le bus d'informations, ladite unite de gestion etant 
destinee a recevoir et a tralter ces evenements en temps reel sans 
I'intermediaire de I'unite centrale, 

30 - une liorloge de datation destinee a dater ces evenements avant de 
les stocker dans une premiere memoire interne a I'unite de gestion, et 
une memoire vive comprenant une table des actions 
preprogrammee, associee a I'unite de gestion, destinee a attribuer des 
actions appropriees aux evenements regus par cette derniere. 

35 Le bus d'informations est un bus standardise du type clnoisi 

parmi un bus PCI, un bus VME, un bus compact PCI, un bus USB. 
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Selon une particularity de I'invention, le module de gestion 
comprend en outre une seconde memoire interne a I'unite de gestion 
permettant de stocker les evenements afin de les lire aux travers du 
bus d'information. 

5 Avantageusement, les premiere et seconde m^moires sont 

du type FIFO et la memoire vive comprenant la table des actions est 
une memoire FIAM double port. 

Breve description des dessins 
10 D'autres particularites et avantages du precede et du 

systeme selon I'invention ressortiront a la lecture de la description 
faite ci-apres, a titre indicatif mais non limitatif, en reference aux 
dessins annexes sur lesquels : 

- la figure 1 est une vue tres schematique d'un module de 
15 gestion des evenements, selon Tinvention, implante dans un systeme 

Informatique standard; 

- la figure 2 est une vue tres schematique d'un module de 
gestion des evenements, selon I'invention, implante dans un systeme 
informatique standard d'une architecture bas6e sur un bus 

20 d'informations de type PCI ; 

- la figure 3 est un schema detaiile d'un module de gestion 
des evenements des figures 1 et 2 ; 

- la figure 4 montre les diff§rentes zones d'un mot stocke 
dans un tableau 

25 des actions selon I'invention ; 

- la figure 5 est un organigramme montrant le deroulement 
general d'un processus de gestion des evenements selon I'invention ; 

- la figure 6 est un organigramme montrant un processus de 
detection des evenements selon la figure 5 ; 

30 - ia figure 7 est une variante de la figure 6 ; 

- la figure 8 est un organigramme montrant un processus de 
traitement des evenements selon la figure 5 ; 

- la figure 9 illustre un exemple de gestion d'un evenement 
en provenance d'un registre d'horloge interne selon I'invention ; 

35 - la figure 10 montre des mots stockes dans un tableau des 

actions selon I'exemple de la figure 9 ; 
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- la figure 1 1 il lustre un exemple de gestlon d'un 6v6nement 
externa selon I'lnvention ; 

- la figure 12 montre des mots stock6s dans un tableau des 
actions selon I'exemple de la figure 1 1 ; et 

5 - la figure 13 est une vue trfes schematique d'un systeme 

informatique standard selon I'art ant6rieur. 

Description d6taill6e des modes de realisation 

La figure 1 montre trfes sch6matiquement I'implantation 
10 d'un module de gestion 60 des evenements, selon I'lnvention, dans un 
systeme informatique standard. Le module de gestion 60 est relie ^ 
I'unite centrale 10 via un bus d'information 50 qui admet un montage 
multi-maTtre ou multiprocesseur permettant ainsi, au module de 
gestion 60 d'agir separement et d'une maniere independante de 
15 I'unite centrale 10. Dans ce cas, le bus d'information 50 est un bus 
standardise du type PCI, VME, compact PCI, ou USB. Ainsi, 
I'implantation du module de gestion 60 transforme le systeme 
informatique standard en un systeme Informatique temps reel. 

La figure 2 est en effet, un exemple d'un module de gestion 
20 60 des Evenements, implante dans un systeme informatique standard 
d'une architecture basee sur un bus d'Informations 50 de type PCI. Le 
bus PC! est un bus synchrone supportant un multiplexage de donn§es, 
d'adresses et de signaux, et permettant un montage multi-maTtre. En 
outre, la specification du bus PCI autorise ^interconnexion et I'emploi 
25 de passerelles ou ponts. Cette figure montre que les unites memoires 
20, peripheriques 30, 40 ainsi que le module de gestion 60 sont 
instances en cascade, a travers des ponts 55, 56, 57 respectivement. Les 
ponts jouent le role des filtres pour les unites qui ne sont pas 
concern§es par le dialogue de I'unite centrale. Ainsi, le pont 57 permet 
30 de mieux Isoler le module de gestion 60 de I'unite centrale 10 lorsque 
ce premier est en dialogue avec d'autres unites electroniques. 

La figure 3 montre de fa^on plus detail lee le module de 
gestion 60 des evenements des figures 1 et 2. Ce module comprend 
une unite de gestion 70, pilotee par une horloge de synchronisation, 
35 par exemple, a une frequence de 33 MHz. Cette unite de gestion 70 
est destinee a recevoir des evenements 80 et a executer des actions 90 




correspondantes en temps reel et sans I'intermediaire de I'unite 
centrale. Au moins une action appropriee est attribuee a chaque 
§venement regu. Pour cela, l'unit§ de gestion 70 est en liaison avec 
une memoire vive 61, par exempie de type RAM double ports, 
5 accessible en lecture et en ecriture. Bien entendu, I'unite de gestion 70 
est connectee au bus d'informatlon 50 au travers d'une interface 63 
standard qui facilite I'echange de donnees avec ce bus dMnformation 
50. Par ailleurs, le module de gestion 60 comporte une pluralite de 
registres d'horloges ou compteurs internes, non repr6sentes sur la 

10 figure et qui peuvent se trouver dans I'unite de gestion 70 ou dans 
I'interface 63. A titre d'exemple, le module de gestion 60 comporte 
seize registres d'horloges d 20-bits cadences a la milliseconde. 

Un evenement 80 est d'une maniere generale, defini par un 
signal de declenchement qui Identifie I'evenement et eventuellement 

15 par un vecteur ou pointeur indiquant a I'unite de gestion 70 I'adresse 
de {'action ou des actions correspondantes a executer, 

Par ailleurs, I'unite de gestion 70 comporte une horloge de 
datation 71, par exempie, d'une frequence de 10 MHz permettant 
ainsi de dater un evenement 80 a la precision de la centaine de 

20 nanosecondes. 

Cette horloge de datation 71 peut etre constitu6, d'un 
premier registre de 16-bits et d'un second registre de 32-bits. Le 
premier registre realise une base de temps intermediaire a 1 
milliseconde, et pilote ensuite le deuxieme registre avec cette base de 

25 temps, de sorte qu'un evenement 80 peut §tre dater pendant 2^^10■^=: 
4,3.10® secondes. 

En outre, I'unite de gestion 70 est associ^e a une premiere 
memoire 73 et a une seconde memoire 74 destinees a stocker les 
^venements 80 regus. De preference, les premiere 73 et seconde 74 

30 memoires sont internes a I'unite de gestion 70. 

A titre d'exemple, la premiere memoire 73 est du type 
« premier entre premier sorti ou FIFO » de 256 mots de 16-bits 
memorisant les evenements qui restent a traiter par ordre 
chronologique. 

35 La deuxieme memoire 74 peut etre constituee de deux 

zones memoires de type FIFO accessibles independamment. Une 




premiere zone memoire est destin^e S stocker des dates en 
millisecondes et une seconde zone m^molre est destin6e ^ stocker les 
evenements. 

La premiere zone m^molre des millisecondes est par 

5 exemple, compos§ de 256 mots de 32-bits representant la date, en 
millisecondes, de I'arr!v6e de I'§v6nement. La seconde zone memoire 
des evenements est par exemple, compose de 256 mots de 32-bits de 
sorte que, les huit bits de poids forts permettent de connaTtre I'origine 
de r6v6nement, les huit bits suivants representant le numero du 

10 vecteur ayant produit I'evenement et les seize bits de poids faibles 
representant le temps en centaines de nanosecondes. 

Conformement h I'invention, la memoire vlve 61 comprend 
une table des actions memorisant des mots qui d§finissent I'action en 
fonction de i'evenement. La figure 4 est un exemple montrant les 

15 differentes zones d'un mot 610 de 32-bits, de la table d'action. Les 
huit bits de poids forts correspondent h un vecteur d'entree 611 
associe a I'evenement, les trois bits suivants repr^sentent Taction 612 
correspondante, les huit bits suivants representent un vecteur de sortie 
613 associi a Taction suivie d'un complement 614 de dnq bits, les 

20 quatre bits suivants representent un signal de sortie 615 et finalement 
les quatre bits de. poids faibles representent le numero 616 d'un 
registre d'horloge. 

On notera que, la table des actions est initialis§e ou ecrite 
avant la mise en marche du traitement des evenements, au travers du 

25 bus d'informations 50, et peut etre lue a tout moment au travers du 
meme bus. 

Un procede de gestion des evenements, selon I'invention, 
sera maintenant decrit en reference aux figures 5 a 8 en plus de la 
figure 3. 

30 La figure 5 est un organigramme montrant le deroulement 

general du processus de gestion des evenements comprenant des 
phases de detection, de traitement et d'observation de ces 
evenements. 

A Tetape 100, un evenement 80 est signaie par un signal de 
35 declenchement qui peut provenir soit de Texterieur du systeme 
informatique, solt ^ travers le bus d'informations 50 par Tecriture 



1 v^i V4c;|^wi 




d'une donnee provenant d'une unite adjacente a I'unlte de gestion 70, 
soit d'un registre d'horloge interne au module de gestion 60, 

A I'etape 200, 1'ev^nement est d^tecte par Tunite de gestion 
70 et est date avec une precision de I'ordre de 100 nanosecondes, 
5 grace a I'horioge de datation 71, L'evenement regu est stocks d'une 
part, dans la premiere memoire 73 (etape 260) et d'autre part, dans la 
seconde memoire 74 avec sa date d'arriv6e (etape 270)^ 

A Tetape 300, les evenements stockes dans la premiere 
memoire interne 73 sont traites d'une maniere synchrone. Ensulte, a 

10 I'etape 340 I'action est executee apres une lecture de la table des 
actions dans la memoire vive 61. L'action peut etre destinee a un 
registre d'horloge, au bus d'Informations, a un generateur de slgnaux 
ou a une interface d'entree-sortie. 

En general, la gestion en temps reel de l'evenement est 

15 inferieure ou egale a environ une microseconde. A titre d'exemple, 
I'arrivee d'un evenement, sa datation et sa memorisation 
correspondent a 2 cycles d'horloge de datation a 10 MHz, c'est-a-dire a 
200 nanosecondes. La recherche de I'action dans la memoire vive 51 a 
double port correspond a 10 cycles d'horloge de synchronisation a 33 

20 MHz, c'est-a-dire S 303 nanosecondes. La preparation du traitement 
correspond a 2 cycles d'horloge de synchronisation a 33 MHz, c'est-^- 
dire a 60,6 nanosecondes. Et, I'execution de Taction, dans le cas d'une 
architecture a bus PCI en mode maitre, correspond a 5 cycles d'horloge 
de synchronisation a 33 MHz, c'est-^-dire k 151,5 nanosecondes. Ainsi, 

25 dans cet exemple, le temps de reponse global est de 715,1 
nanosecondes et done inferieur a 1 microseconde. 

A I'etape 400, les evenements stockes dans la seconde 
memoire interne 74 peuvent etre observes au travers du bus 
d'Informations 50 (etape 450) d'une maniere connue en soi, par 

30 Tintermediaire de Tenvironnement logiciel du systeme informatique 
standard. AinsI, il est possible de controler et de retracer Thistorique 
de ces evenements. 

La figure 5 montre de fagon plus detaillee le processus de 
detection des evenements. De fagon Independante, la nature de 

35 l'evenement regu peut etre constltue d'un signal de declenchement 
interne (etape 110), d'un signal de declenchement externe (etape 



120), d'un signal de declenchement avec un vecteur associ^ en 
provenance du bus d'informations (etape 130) ou d'un signal de 
declenchement externe avec un vecteur associe (etape 140). On notera 
que, des conflits §ventuels entre differents 6v6nements slmultan6s 
5 sont elimln^s, par exemple, de fagon aleatoire. 

Le signal de declenchement interne (etape 110) peut 
r^sulter d'un registre d'horloge interne au module de gestion 60 et 
qui declenche des signaux d des intervalles de temps preprogramm§s. 
Ces intervalles de temps peuvent Mre reguliers, afin de permettre a 
10 I'unite de gestion 70 d'emettre une commande d'emission de donnees 
de fa^on cyclique et determlnlste. L'unite de gestion peut decider la 
mise en route ou l'arr§t de ces registres. Par ailleurs, les registres 
d'horloges peuvent avoir un fonctionnement automatique. 

On notera que, le signal en provenance d'un registre 
15 d'horloge interne etant deja synchronise, on passe alors directement ^ 
une etape 250 apres la reception de ce signal. 

En outre, les evenements re?us aux Stapes 120, 130 et 140 
sont re-synchronises ^ la frequence de I'horloge interne du syst^me 
informatique, aux §tapes 221, 231 et 241 respectlvement avant d'aller 
20 h I'etape 250. Cette frequence de re(-synchronisatlon est par exemple, 
de I'ordre de 10 MHz. 

A I'etape sulvante 250, une date d'arrivee, a la precision de 
la centaine de nanosecondes, est attribute d chaque 6v6nement regu 
par I'horloge de datatlon 71. 
25 A l'§tape 255, les evenements sont identifies par I'unite de 

gestion 70 et le cas 6cheant auto-vectorises, c'est-a-dire que des 
vecteurs sont reserves pour §tre associes d'une part, aux signaux 
externes ne comportant pas de vecteurs et d'autre part, aux signaux 
en provenance des registres d'horloges internes. Ensuite, les 
30 Evenements sont stockes aux etapes 260 et 270. 

A I'etape 260, I'evenement comportant une donnee 
correspondent au signal de declenchement ou d'identification 261 
ainsi qu'une donnee correspondent au vecteur associe 262, est stocke 
dans la premiere memoire interne 73. 
35 A I'etape 270, I'evenement comportant une donn6e 

correspondent au signal de declenchement ou d'identification 271, 
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une donnee correspondant au vecteur assocl6 272 ainsi qu'une donnee 
correspondant ^ la date d'arriv§e 273, est stocke dans la seconde 
m^molre interne 74. 

On notera que, lorsque ia premiere memoire 73 et/ou la 
seconde memoire 74 sont pleines, une interruption est g6n§ree par 
I'unite de gestion 70 vers I'unit4 centrale 10 au travers du bus 
d'informations 50 afin de signaler une eventuelle perte d'un ou de 
plusleurs ^venements d^tectes. II est § remarquer que cette 
interruption est le seul lien, en temps r6el, avec I'unite centrale. 

En variante, un autre processus de detection est lllustr^ par 
la figure 7. li se distingue de celui de la figure 6 en ce qu'aprds les re- 
synchronisations des etapes 221 et 241, les ^venements externes sont 
filtres aux etapes 222 et 242 respectivement avant d'aller a I'etape 
250. Ainsi, pour une meilleure securite, les evenements externes sont 
filtres, par des filtres connus en soi, afin d'eliminer des parasites 
eventuels provenant des p§riph4riques voisins. En revanche, la 
filtration implique une perte de quelques microsecondes et par 
consequent, une augmentation du temps de reponse. 

La figure 8 montre de faqon plus detaillee le processus de 
traitement des evenements. 

Dans le cas oCi un ou plusieurs evenements seraient presents 
dans la premiere memoire interne 73, le processus de traitement se 
d^clenche a I'etape 310. 

A I'etape 320, les vecteurs ou les auto-vecteurs associes aux 
evenements qui sont stockes dans la premiere m6mo!re interne 73 
sont lus de fa^on sequentielle. 

Ensuite, a I'etape 330, le vecteur associe a I'evenement regu 
en premier est recherche dans la table des actions. Si le vecteur 
indique qu'il n'y a plus d'autres actions a executer alors on revient a 
I'etape 310 de debut. Par ailleurs, si le vecteur n'est pas trouve dans la 
table des actions, une interruption est generee et on revient aussi a 
I'etape 310 de debut. En revanche, si le vecteur est trouve, Paction ou 
les actions associees sont executees a I'etape 340, 

Ainsi, en fonctionnement normal, c'est-a-dire mis a part une 
interruption eventuelle, I'unite centrale n'intervient pas dans les 
processus de detection et de traitement de I'evenement. En 
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consequence, une action est ex^cut^e en r^ponse ci un 4v6nement en 
un temps de reponse tres rapide de I'ordre d'une microseconde. 

Par ailleurs, I'unit^ centrale sert par exemple, a initialiser les 
registres d'horloges ou S demarrer I'unit^ de gestlon. Une fois que les 
5 initialisations sont terminees. I'unite centrale n'intervient plus dans le 
processus de gestion des 6venements et peut ainsi, etre employee a 
toutes autres taches. 

Les figures 9 et 10 illustrent un exemple de gestion d'un 
6venement en provenance d'un registre d'horloge interne. 
10 En effet, la figure 9 illustre tres schematiquement, un 

systeme informatique selon I'invention, comportant une unite centrale 
10 reliee via un bus d'informations 50 a un module de gestion 60 et a 
une unite d'interface numerique 85, par exemple une carte de type 
1553, en relation numerique avec un equlpement 87 externe. Pjar 
15 ailleurs, deux registres d'horloges 64 et 65 numirot§s « 0» et « 1 » 
font partie du module de gestion 60. Bien entendu, le nombre de 
registres d'horloges n'est pas limits a deux. 

Au depart, I'unite centrale 10 initialise les registres 
d'horloges 64 et 65 (« 0 » et « 1 ») & 100 mlllisecondes, d§marre 
20 I'unit6 de gestion 70 du module de gestion 60 et initialise \'umt€ 
d'interface numerique 85, au travers du bus d'informations 50. 

Lorsque le registre d'horloge 64 numero « 0 » arrive au bout 
de son comptage, il gen^re un §v6nement «E0 » qui met d'abord en 
arrit le registre « 0 » et qui lance ensuite un second registre d'horloge 
25 65 num4ro « 1 ». Ensuite, I'unite de gestion 70 6crit par exemple la 
donn§e « 55 », au travers du bus d'informations 50, dans I'unite 
d'interface numerique 85 qui provoque remission de donn^es vers 
I'equipement 87 externe. 

Le processus d6crit ci-dessus, peut etre code de la fagon 
30 illustree par la table des actions representee sur la figure 10. 

La premiere ligne indique que sur reception du vecteur 
d'entree 611 « EO = 11100000 », I'action 612 « 010 » arr§te le registre 
d'horloge 64 numero « 0 ». 

La deuxieme ligne indique que I'action 612 «011 » lance le 
35 registre d'horloge 65 numero « 1 ». 



A la troisieme ligne I'actlon 612 «000», Indiquant une 
6crlture a travers le bus d'informations 50, est ex§cut§e en §crlvant le 
vecteur de sortie 613 « 55 » avec un complement 614 « 00000 », a 
I'adresse contenue dans un registre « adresse 1 », de I'unite d'interface 
5 num6rlque 85, Indiqu^ par le signal de sortie 615 « 0000 ». 

La ligne suivante contenant le vecteur d'entree 61 1 « FF = 
1 1 1 1 1 1 1 1 » indique h I'unite de gestion 70 qu'll n'y a plus d'autres 
actions ^ executer pour le vecteur d'entree 61 1 « EO ». 

Les figures 11 et 12 illustrent un exemple de gestion d'un 
10 evenement externe. Cet exemple, concerne une surveillance d'un 
certain seuil de tension predetermine d'un equipement externe. 

En effet, la figure 11 lllustre tres schematiquement, un 
module informatique selon I'invention, comportant une unite centrale 
10, un systeme de gestion 60, une unite d'acquisition analogique 89 et 
15 une unite d'interface numerique 85, par exemple une carte du type 
1553. Ces differentes unites sont reliees entre elles au travers du bus 
d'informations 50. Les unites d'acquisition analogique 89 et 
d'interface numerique 85 sont en relation avec un equipement 87 
externe. L'unite d'acquisition analogique 89 surveille le niveau de 
20 tension de I'equipement 87 externe dont le seul lien avec le module de 
gestion 60 est une liaison numerique a travers I'unite d'interface 
numerique 85. 

L'unite centrale 10 demarre I'unite de gestion 70 du module 
de gestion 60, demande a I'unite d'interface numerique 85 d'envoyer 

25 un message de debut de generation a I'equipement 87 et finalement 
demande a I'unite d'acquisition analogique 89 de commencer une 
surveillance (fleche 88) de la tension de I'equipement 87 externe. A 
partir de cet instant I'unite centrale 10 n'intervient plus dans la 
gestion des evenements. 

30 Lorsque la tension de I'equipement 87 depasse le seuil fixe, 

I'unite d'acquisition analogique 89 genere (fleche 82) un signal de 
declenchement et un vecteur associe, par exemple le vecteur « 1 1 », a 
I'unite de gestion 70. A son tour, I'unite de gestion 70 va scruter la 
table des actions et ecrire une donnee, par exemple « 22 », dans 

35 I'unite d'interface numerique 85. Suite a la reception du vecteur 




« 22 », I'unlte d'interface num^rique 85 va 4mettre (fleche 92) une 
commande ^ I'^quipement 87 externe pour stabiliser la tension. 

Le processus decrit cl-dessus, peut §tre cod6 de la fa^on 
lllustr§e par la table des actions representee sur la figure 12. 

5 Sur reception de I'^v^nement au vecteur d'entr^e 611 « 11 », I' action 
612 « 000 », indiquant une 6criture a travers le bus d'informations 50, 
est ex§cut6e en ecrivant le vecteur de sortie 613 « 22 » avec un 
complement 614 « 00000 », a I'adresse contenue dans un registre 
« adresse 1 », de I'unite d'interface numerique 85, indiqu6 par le 

10 signal de sortie 615 « 0000 ». 

La ligne suivante contenant le vecteur d'entree 611 « FF » 
indique a I'unite de gestion 70 qu'il n'y a plus d'autres actions a 
ex§cuter pour le vecteur d'entree « EO ». 




REVENDiCATIONS 

1. Precede de gestion des evenements, dans un syst^me 
informatique standard comportant une unite centrale (10) connect^e 

5 a des unites nnemoires (20) et des pSripheriques (30, 40) par un bus 
d'informatlons (50) permettant un montage multi-maTtre, 
comprenant les etapes suivantes : 

- recevoir les evenements, 

- dater et stocker ces ev^nements, 

10 - attribuer au moins une action appropriee a chaque evenement regu, 

- executer cette action en reponse a I'evenement regu, 

caracterise en ce que les etapes de gestion precitees sont realisees en 
temps reel sans acceder a I'unite centrale (10), par une unite de 
gestion (70) compris dans un module de gestion (60) independant relie 
15 au bus d'informations (50) et implante dans le systeme informatique 
standard. 

2, Procede de gestion selon la revendication 1, caracterise en 
ce que chaque evenement re^u est stocke dans une premiere memoire 
(73) associee a I'unite de gestion (70). 

20 3. Procede de gestion selon I'une quelconque des 

revendications 1 et 2, caracterise en ce que la gestion en temps reel est 
de I'ordre d'une microseconde. 

4. Procede de gestion selon I'une quelconque des 
revendications 1^3, caracterise en ce que le module de gestion (60) 

25 independant est isole de I'unite centrale (10) par un pont (57). 

5. Procede de gestion selon I'une quelconque des 
revendications 1 a 4, caracterise en ce que ladite action est lue dans 
une table des actions associee a I'unite de gestion (70) et est 
preprogrammee au travers du bus d'information (50). 

30 6. Procede de gestion selon I'une quelconque des 

revendications 1 a 5, caracterise en ce que les evenements regus par 
I'unite de gestion (70) sont dates avec une precision de I'ordre de 100 
nanosecondes et stockes en outre dans une seconde memoire (74) 
associee a I'unite de gestion (70) permettant ainsi de lire ces 

35 evenements aux travers du bus d'informations (50) afin d'enregistrer 
et de controler ces evenements. 
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7. Procede de gestion selon I'une quelconque des 
revendications 1 h 6, caracterise en ce que les 6venements re^us par 
I'unit^ de gestion (70) sont g6n6r§s par un registre d'horloge ( 64, 65) 
interne au module de gestion (60). 
5 8. Proc6d6 de gestion selon I'une quelconque des 

revendications 1 a 6, caracteris6 en ce que les ^venements regus par 
I'unit6 de gestion (70) proviennent d'une unite adjacente (89) au 

module de gestion (60). 

9. Proc4d6 de gestion selon I'une quelconque des 
10 revendications 1 a 6, caracterise en ce que les evenements regus par 

I'unite de gestion (70) proviennent d'un equipement (87) exterieur au 

systeme informatique. 

10. Procede de gestion selon I'une quelconque des 
revendications 8 et 9, caracterise en ce que les evenements re?ys par 

15 I'unite de gestion (70) sont synchronises a une fr^qu.^nce 
correspondante ^ celle d'une horloge interne au systfeme 
informatique. 

11. Proc6d6 de gestion selon I'une quelconque des 
revendications 9, caract§ris§ en ce que les evenements re^us de 

20 I'^quipement (87) exterieur sont f litres afin d'§liminer d'6ventuels 
parasites. 

12. Procede de gestion selon I'une quelconque des 
revendications 1 a 11. caract^risee en ce qu'une interruption est 
g§neree par I'unite de gestion (70) lorsqu'un ev^nement ne peut pas 

25 §tre associe a une action. 

13. IVIodule de gestion des evenements, implante dans un 
systeme informatique standard comportant une unite centrale (10) 
connectee a des unites memoires (20) et des peripheriques (30, 40) par 
un bus d'informations (50) permettant un montage multi-mattre, 

30 caracterise en ce qu'il comprend : 

- une unite de gestion (70) independante, reliee au travers 
d'une interface (63) a I'unite centrale (10) via le bus d'informations 
(50). ladite unit§ de gestion (70) etant destinee a recevoir et a traiter 
ces Evenements en temps r6el sans I'intermediaire de I'unit6 centrale 

35 (10), 




- une horloge de datation (71) destine a dater ces 
§v6nements avant de les stocker dans une premiere m^moire (73) 
interne k I'unit^ de gestion (70), et 

- une m^moire vive (61) comprenant une table des actions 
5 pr6programm§e, assod^e i I'unlte de gestion (70), destinee a attribuer 

des actions approprlees aux 6venements regus par cette derni^re. 

14. Module de gestion selon la revendication 13, caract^rise 

en ce que le bus d'informatlon (50) est un bus standardise du type 

choisi parmi un bus PCI, un bus VME, un bus compact PCI, un bus USB. 
10 15. Module de gestion selon I'une quelconque des 

revendications 13 et 14, caracterise en ce qu'il comprend en outre une 

seconde memoire (74) interne a I'unite de gestion (70) permettant de 

stocker les evenements afin de les lire aux travers du bus 

d'informations (50). 
15 16. Module de gestion selon I'une quelconque des 

revendications 13 a 15, caracterise en ce que les premiere (73) et 

seconde (74) memoires sont du type FIFO. 

17. Module de gestion selon la revendication 13, caracterise 

en ce que la memoire vive (61) comprenant la table des actions est une 
20 memoire RAM double port. 
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